Traditionally, computer based satellite orbit design has been limited to standard mouse and keyboard input interfaces. For example, a user might utilize a graphical user interface (GUI) on a computer display screen 10 by typing in the numerical values of orbital parameters in a visual orbit system 20 one by one using the keyboard in conjunction with text input controls (FIG. 1), or change the orbital parameters using “slider” controls in conjunction with a mouse (FIG. 2). Often this manipulation is accompanied by a visualization which gives the user feedback on how changes to the orbital parameters affect the orbit.
The viewpoint configuration of the orbit visualization might be controlled by keyboard input, for example by using the left or right arrow keys or by manipulation of the visualization surface (displayed) direction arrows by the mouse (FIG. 3). A viewpoint might look directly at the central body's equator, the central body's planetary poles, or anywhere in between.
This traditional approach to computer based design of a satellite orbit in relation to a central body has several disadvantages:                Neither control scheme provides a context for what is being manipulated—it simply allows the user to increase or decrease an opaque value. In other words, there is no connection between the method of manipulation and the nature of the value being manipulated.        Both control schemes are graphically segregated from the visualization, leading to a cognitive disconnect between the two. In other words, it is up to the user to recognize the mapping of the control value to the state of the orbit visualization.        The segregation of viewpoint and orbit manipulation control schemes requires both a cognitive and screen positional shift when switching between the two, introducing workflow inefficiencies.        Continuous cyclic parameters do not map well and end up appearing as if they have finite ranges. For example, a “slider” control mapped to an angle might have a range of 0 degrees to 360 degrees. However, this does not reflect the angle's continuous nature.        
In addition, even if satellite orbit design was performed on a multi-touch enabled device in FIGS. 1, 2 and 3, it would only map the traditional user interface elements using the touch enabled controls provided by the software platform, namely a touch enabled text or command input or a touch enabled “slider” in FIGS. 1, 2 and 3.